Virtual Concatenation is a technique standardised in ITU-T recommendations G.707 and G.783 for use in transport networks, for example, Synchronous Digital Hierarchy (SDH) the European counterpart of Synchronous Optical NETwork (SONET) and Optical Transport Network (OTN).
Referring to FIG. 1, an unprotected SONET/SDH virtual concatenation link 10 is employed to transmit a high bandwidth client signal 12 from a component 20 acting as a source across the link to a component 22 acting as a sink where the signal is re-assembled and transmitted as another high bandwidth client signal 14. The link 10 comprises a plurality of parallel unidirectional channels or members. It will be therefore be appreciated that traffic flowing from the component 22 to the component 20 needs to be transported on a separate link (not shown) comprising channels having their source at the component 22 and corresponding sinks at the component 20. Nonetheless, as explained later, it will be seen that control signals relating to traffic on one link may be returned on the other link and so the two links are not completely independent.
Each Virtual Concatenation link or Virtually Concatenated Group (VCG) has a maximum capacity of 256:64 channels. In SDH terminology a link is designated as: VC-n-256v where n=3,4 for High Order (HO); or VC-n-64v where n=11, 12, 2 for Low Order (LO). In, for example, a VC-4-7v link, an incoming client signal is divided into up to 7 channels. In High Order SONET terminology, link designations are of the form STS-n-Xv, where n=1,3c and Xmax is 256. In Low Order SONET terminology, link designations are of the form VT-n-Xv, where n=1.5,2,3 and Xmax is 64. Each channel is employed to transmit a series of virtual container, for example, VC-4(SDH) or STS-3c (SONET) frames possibly along different physical paths resulting in different propagation delays across the link. In the example of FIG. 1, a group of channels 16 comprising containers VC-4 #1, #2, #3 & #4 is shown as following a long route whereas the group of channels comprising containers VC-4 #5, #6 & #7 is shown as following a short route.
Link Capacity Adjustment Scheme (LCAS), is an enhancement to Virtual Concatenation and has been accepted for inclusion in ANSI standard, T1.105 and approved in ITU-T SG15 recommendation G.7042. LCAS defines the protocol, which is used to change the bandwidth capacity of a Virtual Concatenated link. This is normally carried out in response to a request from a Network Management System (NMS) 30 which is in communication with both components 20,22 and which may have made provision for more channels or which needs to de-provision channels that may be in use. A change in bandwidth may also take place in response to an unplanned channel failure, as indicated by the numeral 24, on one or more in-use channels of a link.
Part of the LCAS methodology is a hand-shake signalling protocol between a source and a sink to achieve a hitless increase or decrease of the link bandwidth (or capacity). It works by switching in (or out) a parallel channel at a precise point in time when the sink has confirmed the channel status back to the source that it is ready to do so. This mechanism is also used when a channel fails (obviously causing a hit indicated by the numeral 24) and must be removed from the link.
Hand-shake information is contained in a VC-4 frame header. For the purposes of the present description, in the case of High Order LCAS, one byte of this header H4 is of relevance, H4 information is built up over 16 frames to provide control information for a multi-frame. FIG. 2 shows the semantics of the 4 most significant bits (MSB) of the H4 bytes for frames 0 to 15 of a LCAS high order multi-frame. In the case of Low Order LCAS, FIG. 11(a), the hand-shake information is contained in a 32-bit string of bit 2 of the K4 byte. This 32 bit string is built up over 32 four-frame multi-frames to provide LCAS control information.
Some of these blocks such as SQ, Ctrl, GID and CRC-8 are populated by a component acting as a source and relate to traffic it is providing to a sink on one link. Other blocks, such as MST, RS-Ack, MFI-2, are provided on a return link by the component acting as the sink for such traffic.
In particular, a sink provides channel status information on the return link by setting the respective bits of MST_MSB and MST_LSB indicated by the numeral 34 to provide the state of up to 8 channels in a multi-frame. MFI-2_MSB and MFI-2 LSB indicated by the numeral 32 give the frame count within a multi-frame and so identify which 8 of a total of 256/64 channel states are being provided in the multi-frame.
Thus, the status of all possible channels (256 HO; 64 LO) are reported back through a return channel in batches of eight within each multi-frame. The first multi-frame carries 0–7, the second 8–15, the third 16–23 etc. until all 256HO/64LO are reported and the process repeats. It should be noted that the same batch status is reported on all return channels, so for example if there are seven return channels, they all carry the same status information.
Each frame of a multi-frame takes 125 μs to transmit and so a multi-frame comprising 16 frames takes 2 ms to transmit. For high order LCAS, it takes 32 multi-frames to transmit the channel status of all 256 channels of a link. Thus, channel status confirmation from the sink can take up to 64 ms for high order LCAS. A low order multi-frame takes 16 ms to transmit and 8 multi-frames are required to transmit the status of all 64 channels. Thus, in the case of low order LCAS it takes 128 ms to return channel status information.
In the SONET/SDH non-protected scenario, if one or more of the diversely routed channels is ‘hit’, the remaining channels can continue to carry the data, albeit at a reduced bandwidth. However, the LCAS scheme cannot be guaranteed to recover before the sink response time of 64 ms/128 ms. This does not include the propagation delay of the link. Where this propagation delay is large by comparison to the response time, it means that many frames will be transmitted down a hit channel before the source recovers.
It is therefore desirable to improve the response time for adjusting the capacity of a link, particularly, in response to a failure.